home *** CD-ROM | disk | FTP | other *** search
/ Aminet 37 / Aminet 37 (2000)(Schatztruhe)[!][Jun 2000].iso / Aminet / dev / misc / AWNP_2-39.lha / AWNP / AWNP-Docs / extensions.doc < prev    next >
Text File  |  2000-03-06  |  5KB  |  111 lines

  1. X or x option
  2. ==============
  3.  
  4. The X option is always followed by additional character(s). The second character determines what type of pipe is opened.
  5.  
  6. X0[(r|w)filename]
  7.  
  8.  Programmable replacement of a character. A single character is looked for in data written to the pipe and replaced by a multicharacter string.
  9.  
  10.  First write two bytes to the pipe. the first byte is always '1' the second byte is the target character to be replaced. Then write a byte giving the length of the
  11. replacement string (<=255) followed by the replacement string. Do NOT include a terminating null .
  12.  
  13.  Data written to the pipe after this point is echoed back to the pipe with any occurrences of the target character replaced by the specified string.
  14.  
  15.  X0wfilename causes the data to be echoed to a file rather than back to the pipe.
  16.  
  17.  X0rfilename causes the data to be read from a file rather than from the pipe. Note that the target character and replacement string is still read from the pipe not the
  18. external file. Only data to be parsed and replaced is read from the file.
  19.  
  20. Xi[filename]
  21.  
  22.  The icon file for the specified file (you do NOT add '.icon') is read. The pipe returns the following lines...
  23.  
  24. icon_type x y stack
  25. default tool
  26. tool window
  27. first tooltype
  28. second tooltype
  29. ...
  30.  
  31. If no icon file is found  no data is returned. Note that for blank lines will be returned when the information does not apply to that icon type.
  32.  
  33. example: awnpipe:/xidevs:dosdrivers/awnpipe  returns
  34.  
  35. 4 3 139 4096
  36. C:Mount
  37.  
  38. ACTIVATE=0
  39.  
  40. To get information on a volume (say dh1:) use 'awnpipe:/xidh1:disk'.
  41.  
  42. Xm[c][(r|w)filename]
  43.  
  44.  Pattern match Conversation. This conversation supports full ADOS pattern matching. The trailing 'c' will make the match case sensitive.
  45.  
  46.  Xmwfilename causes the match result to be sent to a file rather than back to the pipe.
  47.  
  48.  Xmrfilename causes the data to be read from a file rather than from the pipe. The match results are read back from the pipe.
  49.  
  50. NOTE: the replies are ascii terminated with a newline.
  51.  
  52. Write the pattern to the pipe terminated with a newline. (<500 chars) The pipe returns 'ok 1' when you sent a valid pattern to match to. It returns 'ok 0' if you dis not send a pattern ( the pipe will look only
  53. for exact matches).
  54.  
  55. write a string to the pipe terminated with a newline.(<500 chars) read the reply  '0' (no match) '1' (is a match)
  56.  
  57. write as many stings as you like . Close pipe to end. The terminating newlines are ignored while matching.
  58.  
  59.  
  60. Xk
  61.  
  62.  Filter keystrokes from the input device event stream and receive notifications of the keystroke.
  63.  
  64.  First write a byte to the pipe setting the priority of the key parse handler. It is a signed byte -128 to 127. If you are not sure what you want use 51 (0x33).
  65.  
  66.  Next  write a byte to the pipe indicating how many keystrokes to filter. The maximum is 255 (0x'ff'). 0 is NOT valid.
  67.  
  68. 0x'0a' is 10 keys.
  69.  
  70.  Then write two bytes to the pipe indicating how often a null match should be sent (to stop your task waiting forever for a match that never happens).
  71.  
  72. 0x'0032' is 50/100s of a second.
  73.  
  74.  Now write 4 bytes defining each key you wish to be notified of.  The first two bytes are the key the second two bytes are the qualifier.
  75.  
  76.  Writing 0x'00200001' to the pipe sets the 'a' key 'leftshifted' to be filtered fron the event stream.
  77.  
  78.  You MUST set exactly the same amount of keys as specified above.
  79.  
  80.  Once the setup is complete you read notification from the pipe. Each notification is 1 byte giving a match number, the first keystroke you specified is 1, the second 2 ...
  81.  
  82.  A byte of 0 is a null event, no match occured.
  83.  
  84.  Close the pipe to end key filtering. NOTE the keparse handler actualy does not get removed until the NEXT match or null event.
  85.  
  86. Xe
  87.  
  88.  Write keystrokes to the input device event stream.
  89.  
  90.  Each keystroke is sent by writing 4 bytes to this pipe. The first two bytes are the key the second two bytes are the qualifier.
  91.  
  92.  Writing 0x'00200001' to the pipe sends the 'a' key 'leftshifted'.
  93.  
  94.  You may close the pipe at any time.
  95.  
  96. Xea
  97.  
  98.  Write keystrokes to the input device event stream from a string source.
  99.  
  100.  Each keystroke is sent by writing a byte to this pipe. You do NOT need to write one character at a time. Simply write ascii text to the pipe and it will generate keystrokes as if the string had been typed at the keyboard.
  101.  
  102.  This is easier than writing keycodes and qualifiers to the pipe but you can not generate 'special keystrokes' like Alt-F10 .
  103.  
  104.  You may close the pipe at any time.
  105.  
  106. Xc[(r|w)filename]
  107.  
  108.  ClassAct Window Conversation. The Window and gadgets are defined by writing to the pipe:. Gadget hits and error/confirmation information is read from the pipe. A filename may also be given. If the file is specified as write 'w' the output of the pipe is directed to that file. If the file is specified as read 'r' the window and gadget definitions are read from the file.
  109.  
  110. See GUI Creation for more details.
  111.